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5 

PRIORITY 

The present application claims priority from the following commonly- 
owned United States patent application, which is hereby incorporated herein 
10 by reference in its entirety: 

United States Provisional Patent Application No. 60/225,335 entitled 
OPTICAL SERVICE AGENT, which was filed on August 15, 2000 in the 
names of Bruce A. Schofield, William R. Hawe, Paul D. Callahan, Indermohan 
Monga, Stephen Suryaputra, and Andre N. Fredette. 

15 

CROSS-REFERENCE TO RELATED APPLICATION(S) 

The present application may be related to the following commonly- 
20 owned United States patent applications, which are hereby incorporated 
herein by reference in their entireties: 

United States Patent Application No. XX/XXX,XXX entitled OPTICAL 
SWITCH ROUTER, which was filed on even date herewith in the names of 
Bruce A. Schofield, James V. Luciani, and Michael J. Craren; 
25 United States Patent Application No. XX/XXX,XXX entitled SYSTEM 

AND DEVICE FOR PROVIDING COMMUNICATION SERVICES IN AN 
OPTICAL COMMUNICATION SYSTEM, which was filed on even date 
herewith in the names of Bruce A. Schofield, Indermohan S. Monga, and 
Stephen Suryaputra; and 
30 United States Patent Application No. XX/XXX,XXX entitled SYSTEM, 

DEVICE, AND METHOD FOR MANAGING COMMUNICATION 
SERVICES IN AN OPTICAL COMMUNICATION SYSTEM, filed on even 
date herewith in the names of Bruce A. Schofield, William R. Ha we, Paul D. 
Callahan, Indermohan S, Monga, Stephen Suryaputra, and Andre N. Fredette. 
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10 


FIELD OF THE INVENTION 

The present invention relates generally to optical networking, and 
more particularly to managing communication services in an optical 
communication system. 

BACKGROUND OF THE INVENTION 


In today's information age, communication networks are increasingly 
used for transferring information among a multitude of communication 
devices. As demand for communication services continues to grow, the 
demand on these communication networks for carrying increasing amounts 
15 of information at increasing speeds continues to grow. Therefore, 

communication networks are evolving to handle these increased demands. 

One way in which communication networks are evolving is through 
the use of optical communication facilities. Optical communication facilities 
20 transport information over optical communication media (such as optical 
fibers). Such optical communication networks provide vast amounts of 
bandwidth over short and long distances. 

The optical communication network is capable of providing various 
25 communication services to its users. Traditionally, such communication 
services have been very expensive, and need to be planned and scheduled 
well in advance. This is due in part because changes to the optical 
communication network, such as provisioning and switching optical 
communication paths, required substantial human intervention. 

30 

SUMMARY OF THE INVENTION 

In accordance with one aspect of the invention, an optical service agent 
35 is used to manage connection establishment and related services on behalf of 
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a user. The optical service agent may negotiate various connection and 
connection-related services, model connections, reserve communication 
services, establish connections on behalf of the user, and aggregate multiple 
optical communication paths over a connection, to name but a few. The 
optical service agent may interact with an optical communication network 
and /or various peer users in order to obtain and reserve communication 
services. 


BRIEF DESCRIPTI ON OF THE DRAWINGS 

In the accompanying drawings: 

FIG. 1 is a network diagram showing a representation of a 
communication system in which users communicate over an automatically 
switched optical network (ASON) in accordance with an embodiment of the 
present invention; 

FIG. 2 is a network diagram showing an exemplary ASON in 
accordance with an embodiment of the present invention; 

FIG. 3 is a block diagram showing relevant components of an 
exemplary ASON device in accordance with an embodiment of the present 
invention; 

FIG. 4 is a block diagram showing an ASON-enabled user including an 
ASON-enabled user application in accordance with an embodiment of the 
present invention; 

FIG. 5 is a network diagram showing an exemplary communication 
system in which ASON-enabled users communicate over an ASON in 
accordance with an embodiment of the present invention; 

FIG* 6 is a block diagram showing an OSA-enabled user including an 
embedded OSA in accordance with an embodiment of the present invention; 

FIG* 7 is a diagram showing the relationship between a user 
application and the OSA in accordance with an embodiment of the present 
invention; 
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FIG. 8 is a diagram showing the relationship between the OSA-A and 
the OSA-N in accordance with an embodiment of the present invention; 

FIG. 9 is a diagram showing an exemplary system in which the OSA-N 
resides in the OSA-enabled user in the edge system in accordance with an 
5 embodiment of the present invention; 

FIG. 10 is a diagram showing an exemplary system in which the OSA- 
N resides in the ASON user at the edge of the ASON in accordance with an 
embodiment of the present invention; 

FIG. 11 is a diagram showing an exemplary system in which the OSA- 
10 N resides outside of the OSA-enabled user and the ASON device in a proxy 
arrangement in accordance with an embodiment of the present invention; 

FIG. 12 is a diagram depicting how OSA-N functionality is handled by 
the OSS in accordance with a client-server embodiment of the present 
invention; 

15 FIG. 13 is a message flow diagram depicting various exchanges 

between the OSA-N and the OSS in accordance with a client-server 
embodiment of the present invention; 

FIG. 14 is a diagram depicting how authentication is handled by the 
OSA in accordance with a distributed flooding embodiment of the present 

20 invention; 

FIG. 15 is a message flow diagram depicting various exchanges 
between the OSA-N and the OSS in accordance with a distributed flooding 
embodiment of the present invention; 

FIG. 16 is a diagram depicting how authentication and flooding are 
25 handled by the OSS in accordance with a hybrid /proxy embodiment of the 
present invention; 

FIG. 17 is a message flow diagram depicting various exchanges 
between the OSA-N and the OSS in accordance with a hybrid/ proxy 
embodiment of the present invention; 
30 FIG. 18 is a network diagram showing an exemplary communication 

system in which an OSA-enabled user communicates with an ASON-enabled 
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user over the ASON in accordance with an embodiment of the present 
invention; 

FIG. 19 is a network diagram showing an exemplary communication 
system in which two OSA-enabled users communicate over the ASON in 
5 accordance with an embodiment of the present invention; 

FIG. 20 is a block diagram showing relevant components of the OSA in 
accordance with an embodiment of the present invention; 

FIG. 21 is a logic flow diagram showing exemplary OSA logic for 
managing communication services in accordance with an embodiment of the 
10 present invention; 

FIG. 22 is a message flow diagram demonstrating an authenticated 
auto-discovery process in accordance with an embodiment of the present 
O invention; 

£ FIG. 23 is a message flow diagram demonstrating the process of 

2 15 removing an OSA-enabled user from a peer group in accordance with an 
% 1 embodiment of the present invention; 

Lf j FIG. 24 is a logic flow diagram showing exemplary OSA logic for 

Q managing various connection establishment services on behalf of the network 

user in accordance with an embodiment of the present invention; 
U "| 20 FIG. 25 is a logic flow diagram showing exemplary OSA logic for 

U negotiating various connection and connection-related services on behalf of 

the OSA-enabled user in accordance with an embodiment of the present 

invention; 

FIG. 26 is a logic flow diagram showing exemplary OSA logic for 
25 modeling one or more connections for the OSA-enabled user in accordance 
with an embodiment of the present invention; 

FIG. 27 is a logic flow diagram showing exemplary OSA logic for 
establishing a connection for the OSA-enabled user in accordance with an 
embodiment of the present invention; 
30 FIG. 28 is a logic flow diagram showing exemplary OSA logic for 

reserving connection and connection-related services for the OSA-enabled 
user in accordance with an embodiment of the present invention; and 
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FIG. 29 is a logic flow diagram showing exemplary OSA logic for 
aggregating multiple optical communication paths over a single connection in 
accordance with an embodiment of the present invention. 

5 

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 

In an embodiment of the present invention, an optical service agent 
(OSA) operating within the domain of the network user manages connection 

10 establishment and related services on behalf of the network user. The OSA 
interacts with the optical communication network to obtain various 
communication services and manages those communication services for the 
network user based upon predetermined parameters defined by the network 
user. In essence, then, the optical communication network provides a "core" 

15 set of communication services that can be accessed by the OSA, and the OSA 
provides advanced communication services for the network user using the 
"core" set of communication services provided by the optical communication 
network. 

20 In an agile transport network, various optical communication services 

that heretofore have been performed manually are performed automatically 
by "intelligent" optical communication devices within the network. In 
particular, the optical internet infrastructure is evolving from a statically- 
provisioned SONET ring-based transport network to a more dynamically- 

25 provisioned mesh network. 

One example of an agile transport network is an automatically 
switched optical /transport network (ASON or ASTN), which is described in 
the related application entitled SYSTEM AND DEVICE FOR PROVIDING 
30 COMMUNICATION SERVICES IN AN OPTICAL COMMUNICATION 
SYSTEM incorporated by reference above. The ASON typically includes 
optical cross-connect switches (OXCs) that are used to form the mesh network 
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and optical channel controllers (OCCs) that dynamically create, delete, and 
modify optical communication paths by controlling the OXCs through a 
connection control interface (CCI). For convenience, the OXCs and OCCs are 
referred to hereinafter collectively as ASON devices. The ASON devices, and 

5 in particular the OCCs, are typically network routers that use a link-state 
routing protocol (e.g., OSPF) to distribute link attributes (such as optical 
channel availability) and a signaling protocol (e.g., MPLS or GMPLS) to 
manage optical communication paths end-to-end. These protocols enable the 
ASON to automatically and quickly create, delete, and modify optical 

10 communication paths. The ASON typically also includes an optical service 
server (OSS) for coordinating the various communication services provided 
by the ASON. Thus, the ASON provides more agility by moving from 
manual provisioning to automatic provisioning via switching and signaling. 

15 In essence, then, the ASON is an optical/transport network that has 

dynamic connection capabilities. Among other things, the ASON provides for 
discovery of physical topology for optical elements, efficient use of available 
bandwidth by dynamic creation of optical communication paths, and end-to- 
end connection protection and restoration. 

20 

FIG. 1 shows a representation of a communication system 100 in which 
two users 110, 130 communicate over an ASON 120. The users 110, 130 may 
be optical switch routers, as described in the related application entitled 
OPTICAL SWITCH ROUTER incorporated by reference above, that are 
25 positioned as edge nodes of their respective user networks for interfacing 

with the ASON 120. The ASON 120 provides various communication services 
to the users 110, 130 via the automatic servicing logic. Various ASON 
communication services are discussed in more detail below. 

30 Each ASON device includes an ASON controller for supporting 

automated communication services within the ASON 120. Among other 
things, the ASON controller enables each ASON device to automatically 
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provision, switch, and signal optical communication paths within the ASON 
120. The ASON controller enables carriers and service providers to offer 
many value-added services to their customers. 

5 In order for the users 110, 130 to control and monitor communication 

services from the ASON 120, the ASON controller provides a user-to-network 
interface (UNI) through which the users 110, 130 interact with the ASON 
controller for controlling and monitoring communication services within the 
ASON 120. Through the ASON UNI, the users 110, 130 can access various 

10 controllable features of the ASON 120. For example, using the ASON UNI, 
the users 110, 130 can request an optical communication path having certain 
attributes, renegotiate the attributes of the optical communication path, 
control switching of the optical communication path, terminate the optical 
communication path, and monitor operation of the ASON 120, to name but a 

15 few. 

Within the ASON 120, each ASON device is able to perform various 
functions in support of the automated communication services. Some of these 
functions can be carried out by an individual ASON device, while others of 

20 these functions require coordination among multiple ASON devices. 

Therefore, the ASON controller provides a network-to-network interface 
(NNI) that enables communication between ASON devices for coordinating 
various communication functions. Through the ASON NNI, the various 
ASON devices can exchange ASON routing information and coordinate such 

25 things as establishment and termination of optical communication paths, 
switching of optical communication paths, and protection and restoration of 
optical communication paths, to name but a few. 

FIG. 2 shows an exemplary embodiment of the ASON 120 having four 
30 ASON devices 210, 220, 230, 240 and OSS 250. For convenience, the solid lines 
shown between the ASON devices 210-240 represent optical communication 
paths, which may be all-optical paths (lightpaths) or partially optical paths 
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(switch-paths), and the dashed lines shown between the ASON devices 210- 
240 show the type of interface (UNI or NNI). The users 110, 130 interface with 
the ASON 120 through ASON device 210 and ASON device 240, respectively. 
The ASON devices 210, 240 provide a UNI to the users 110, 130, respectively, 

5 through which the users 110, 130 can control and monitor communication 
services provided by the ASON 120, and more specifically by the ASON 
controller within the ASON devices 210-240. The ASON devices 210-240 are 
interconnected via the NNI, and use the NNI to interoperate for coordinating 
various communication functions. It should be noted that the ASON NNI 

10 may utilize separate communication paths from the optical communication 
paths. The OSS 250 coordinates the various communication services provided 
by the ASON devices 210-240. 

At the heart of the various automated communication services is 
15 automatic switching of optical communication paths. In order to support 
automatic switching of optical communication paths within the ASON 120, 
the ASON devices 210-240 typically include some form of optical switching 
logic, such as an optical/photonic switching fabric, for performing 
optical/photonic switching of optical communication paths. The optical 
20 switching fabric may be based upon any of a variety of optical / photonic 
switching technologies, including, but not limited to, Micro Electro 
Mechanical System (MEMS) technology, Micro Opto Electro Mechanical 
System (MOEMS) technology, lithium niobate technology, liquid crystal 
technology, or other optical/photonic switching technology. The optical 

25 switching logic can be dynamically configured under control of the ASON 
controller for such things as passing optical data streams from a number of 
incoming optical fibers to a number of outgoing optical fibers (i.e., switching), 
adding an optical data stream to an outgoing optical fiber, and dropping an 
optical data stream from an incoming optical fiber for local processing by the 

30 ASON device, to name but a few. 
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FIG. 3 shows the relevant components of an exemplary ASON device 
300. Among other things, the ASON device 300 includes a number of 
incoming optical interfaces 310, a number of outgoing optical interfaces 330, 
optical switching logic 320, ASON controller 340, ASON UNI 350, ASON NNI 
5 360, ASON Network Management Interface (NMI) 370, and network 

management/optimization elements 380. The incoming optical interface(s) 
310 are couplable to a number of incoming optical fibers for receiving optical 
data streams at various wavelengths. The outgoing optical interface(s) 330 are 
couplable to a number of outgoing optical fibers for outputting optical data 
10 streams at various wavelengths. The optical switching logic 320 is interposed 
between the incoming optical interface(s) 310 and the outgoing optical 
interface(s) 330 for switching optical data streams, which may include such 
things as passing certain optical data streams received over the incoming 
optical interface(s) 310 through to the outgoing optical interface(s) 330, 
15 dropping one or more optical data streams received over the incoming optical 
interface(s) 310 for local processing by the ASON device 300, and adding one 
or more optical data streams to the outgoing optical interface(s) 330, to name 
but a few. The ASON controller 340 automates certain communication 
services by controlling, among other things, the incoming optical interface(s) 
20 310, the optical switching logic 320, and the outgoing optical interface(s) 330. 
The ASON UNI 350 enables a user to control and monitor communication 
services provided by the ASON controller 340. The ASON NNI 360 enables 
the ASON controller 340 within the ASON device 300 to interact with the 
ASON controller in other ASON devices for coordinating communication 
25 services within the ASON 120. The ASON UNI 350 and the ASON NNI 360 
are typically integral to the ASON controller 340, but are shown here 
separately for convenience. The ASON NMI 370 is a network management 
interface between the ASON controller 340 and various network 
management/ optimization elements 380. Among other things, the ASON 
30 controller 340 provides network status information to the network 

management/ optimization elements 380 and receives network updates from 
the network management/ optimization elements 380 via the ASON NMI 370. 
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Without limitation, the ASON 120 can provide practically any 
communication service that has traditionally been performed manually. As 
described in the related application entitled SYSTEM AND DEVICE FOR 

5 PROVIDING COMMUNICATION SERVICES IN AN OPTICAL 
COMMUNICATION SYSTEM incorporated by reference above, some 
exemplary communication services that can be provided by the ASON 120 
include "plug and play" for optical elements, modeling of optical 
communication paths, automatic provisioning of optical communication 

10 paths, user-requested switching of optical communication paths, automatic 
switching based upon service level agreement (SLA), automatic switching for 
protection and restoration, bandwidth management, and reporting of 
statistical and other information, to name but a few. It should be noted that 
the present invention is in no way limited to any particular communication 

15 services provided by the ASON 120. 

As discussed above, the ASON UNI enables the users to control and 
monitor communication services provided by the ASON 120. The ASON UNI 
provides a standardized interface to the ASON 120, and more particularly to 
20 the ASON controller 340 in the ASON device. Conceptually, the ASON UNI 
provides a set of "control knobs" through which the users can control and 
monitor ASON communication services. 

One way for a user to access ASON communication services is by 
25 implementing some or all of the ASON UNI functionality. For example, 

ASON UNI functionality can be integrated with a user application so that the 
user application can access ASON communication services. For convenience, 
such a user is referred to hereinafter as an ASON-enabled user, and such a 
user application is referred to hereinafter as an ASON-enabled user 
30 application. 
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FIG. 4 shows an ASON-enabled user including an ASON-enabled user 
application 410. The ASON-enabled user application 410 implements some or 
all of the ASON UNI functionality. The ASON-enabled user application 410 
communicates with the ASON controller 340 in the ASON device over a UNI 
5 signaling channel 420, using the ASON UNI in order to obtain 

communication services from the ASON 120. The UNI signaling channel 420 
may be, for example, an in-band signal carried over a SONET Data 
Communication Channel (DCC). 

10 FIG. 5 shows an exemplary communication system 500 in which two 

ASON-enabled users 510, 520 communicate over the ASON 120. Each of the 
ASON-enabled users 510, 520 implement some or all of the ASON UNI, and 
therefore are able to monitor and control certain communication services 
provided by the ASON 120. For example, using the ASON UNI, the ASON- 

15 enabled users 510, 520 can establish an end-to-end optical communication 

path for communicating over the ASON 120. The optical communication path 
has certain attributes that are negotiated between the two ASON-enabled 
users 510, 520 and also between the ASON-enabled users 510, 520 and the 
ASON 120. 

20 

Unfortunately, it is not always practical to implement the ASON UNI 
in each user application that requires ASON communication services. 
Therefore, another way for the user to access ASON communication services 
is by employing an optical service agent (OSA) to manage communication 

25 services for the user. As described in the related application entitled 
SYSTEM, DEVICE, AND METHOD FOR MANAGING 
COMMUNICATION SERVICES IN AN OPTICAL COMMUNICATION 
SYSTEM incorporated by reference above, the OSA is an intelligent, 
embedded signaling agent that operates within the user at the edge of the 

30 ASON 120. The OSA implements application-specific services and 
intelligence as well as the ASON UNI and other mechanisms for 
communicating with the ASON controller 340 via the ASON UNI. The OSA 
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can be viewed as a subsystem that understands user requirements and 
manages various communication services on behalf of the user to meet the 
user requirements. Specifically, the OSA interacts with the ASON 120 via the 
ASON UNI to obtain various communication services and manages that 
5 communication services for the user based upon predetermined parameters 
defined by the user. Architecturally, the OSA is layered above the ASON 
UNI, and uses the ASON UNI to manage and control ASON communication 
services provided through the ASON controller 340. In essence, then, the 
OSA provides advanced communication services for the user using the 
10 "control knobs'" provided by the ASON UNI. For convenience, a user that 
employs an OSA for managing communication services is referred to 
hereinafter as an OSA-enabled user. 

FIG. 6 shows an OSA-enabled user including an embedded OSA 610. 

15 The OSA 610 implements application-specific services and intelligence as well 
as the ASON UNI and other mechanisms for communicating with the ASON 
controller 340 via the ASON UNI. The OSA 610 communicates with network 
management/ optimization elements 380 in the ASON 120 via a network 
management interface 620, and communicates with the ASON controller 340 

20 in the ASON device via the ASON UNI 630 in order to obtain communication 
services from the ASON 120, specifically by sending service requests to the 
ASON controller 340 and receiving service responses from the ASON 
controller 340. The OSA 610 manages the communication services for the user 
based upon predetermined parameters defined by the user. The ASON 

25 controller 340 provides network status information to the network 

management/ optimization elements 380 and receives network updates from 
the network management /optimization elements 380 via the ASON NMI 370. 

The OSA 610 is typically implemented in software, and can be 
30 implemented in a platform dependent or platform independent manner. In a 
platform dependent OSA implementation, the OSA 610 is implemented 
specifically for a particular platform, and is typically not portable to other 
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platforms. In a platform independent OSA implementation, the OSA 610 is 
implemented so as to work with multiple platforms, for example, by 
separating platform-specific functions from the higher level protocols and 
algorithms and implementing the platform-specific functions separately from 

5 the higher level protocols and algorithms such that the higher level 

protocol /algorithm "layer" can be used with the platform-specific "layer " for 
a particular platform. The suitability of a particular programming language 
for implementing the OSA 610 may depend on the type of implementation 
(platform dependent or platform independent) as well as the execution 

10 frequency of the OSA 610. For example, a Java implementation may be 

suitable for a platform independent implementation in which the OSA 610 is 
executed infrequently, while a C++ implementation may be more suitable for 
platform dependent implementations as well as applications in which the 
OSA 610 is executed more frequently. 

15 

Whether the OSA 610 is implemented in a platform dependent or 
platform independent manner, the OSA 610 typically includes various user- 
controllable and user-customizable features. In order for a user application to 
access these user-controllable and user-customizable features, the OSA 610 

20 typically includes an OSA Application Program Interface (API) that includes 
various primitives for accessing the user-controllable and user-customizable 
features of the OSA 610. The OSA API is typically simpler than the ASON 
UNI, particularly because the OSA API is typically an internal software 
interface that does not need to implement the complexities of the ASON UNI 

25 (such as mechanisms for communicating over a UNI signaling channel). 

FIG. 7 shows the relationship between a user application 710 and the 
OSA 610. The OSA 610 provides an OSA API through which the user 
application 710 can access the OSA 610. The OSA API includes various 
30 primitives for accessing the user-controllable and user-customizable features 
of the OSA 610. 
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In a typical embodiment of the OSA 610, the OSA 610 is separated into 
two components, namely an application component (referred to hereinafter as 
the OSA- A) and a network component (referred to hereinafter as the OSA-N). 
The OSA-A and the OSA-N communication via a control interface, which, 
depending on the placement of the OSA-N (discussed below), may be the 
ASON UNI or another control interface. 

The OSA-A is the application piece of the OSA 610. The OSA-A 
implements application-specific services and intelligence. Because the OSA-A 
is so tightly coupled to the user application, the OSA-A typically resides on 
the user platform in the edge system. The OSA-A manages communication 
services on behalf of the user, specifically by requesting communication 
services from the ASON 120 via the OSA-N and mapping communication 
services from the ASON 120 to the user network or application. 

The OSA-N is the network piece of the OSA 610. Among other things, 
the OSA-N provides functionality for user authentication, registration, and 
membership. Authentication functionality enables the network to 
authenticate the user in order to ensure that the user is permitted to access 
ASON communication services. Registration functionality enables the user to 
register a user identifier with the network. For example, in an Internet Service 
Provider (ISP) application, the user identifier is typically the address of the 
router attachment to the ASON device (i.e., the IP address of the ASON 
controller and the UNI control channel identifier), which can be viewed as the 
L1/L2 address of the router interface. Membership functionality enables the 
user to join a multicast group along with other peer users of the ASON 120. 
The OSA-N may reside on the user platform in the edge system or in the 
ASON device at the edge of the ASON 120. 

FIG. 8 shows the relationship between the OSA-A 810 and the OSA-N 
820. The OSA-A implements application-specific services and intelligence for 
managing communication services on behalf of the user. The OSA-N 
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provides functionality for user authentication, registration, and membership. 
The OSA-A and the OSA-N communicate via the OSA control interface 830. 

FIG. 9 shows an exemplary system in which the OSA-N 820 resides in 
5 the OSA-enabled user in the edge system. Specifically, the OSA-enabled user 
includes both the OSA-A 810 and the OSA-N 820. The OSA-A 810 and the 
OSA-N 820 communicate via the OSA control interface 830. In this case, the 
OSA control interface 830 is typically a software interface between the OSA-A 
810 and OSA-N 820 components. The OSA-A 810 implements application- 
10 specific services and intelligence. The OSA-N 820 provides functionality for 
user authentication, registration, and membership, and implements the 
ASON UNI and other mechanisms for communicating with the ASON 
controller 340 in the ASON device. In this configuration, the OSA-N 820 can 
be implemented as a device driver for the specific UNI signaling channel 
15 interface between the OSA-enabled user and the ASON device. The OSA-A 
810 can be used over different types of UNI signaling channels, for example, 
by installing an appropriate OSA-N device driver that supports the UNI 
signaling channel for a particular application. 

20 FIG. 10 shows an exemplary system in which the OSA-N 820 resides in 

the ASON user at the edge of the ASON 120. Specifically, the ASON device 
includes the OSA-N 820 and the ASON controller 340. The OSA-A 810 in the 
OSA-enabled user communicates with the OSA-N 820 in the ASON device via 
the ASON UNI. With the OSA-N 820 resident in the ASON device, the ASON 

25 device (i.e., the service provider) can provide advanced communication 

services to the OSA-enabled user that are controlled through the OSA-A 810. 

FIG. 11 shows an exemplary system in which the OSA-N 820 resides 
outside of both the OSA-enabled user and the ASON device in a proxy 
30 arrangement. In this proxy arrangement, the OSA-enabled user is not 

required to support the ASON UNI signaling channel over the bearer channel 
1110. Instead, a separate control channel 830 can be established for 
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communication between the OSA-A 810 in the OSA-enabled user and the 
OSA-N 820. The OSA-A 810 sends requests to the OSA-N 820 for ASON 
services, and the OSA-N 820 carries out the requests using the ASON UNI. 
Such a proxy-based OSA/UNI can be useful in extending ASON services to 
5 legacy optical edge equipment. 

In order to guarantee service to its users and maintain integrity of the 
optical core, the ASON 120 needs to provide a level of security and 
authentication. The fact that there is an enabled physical connection between 

10 an ASON-enabled user and the ASON device may be sufficient authentication 
for the ASON-enabled user to access the ASON 120. However, as ASON 
usage grows and OSA is deployed, the ASON 120 will need to authenticate 
the OSA-enabled users so that only authorized OSA-enabled users are able to 
access the ASON 120. Therefore, the ASON 120 will authenticate each OSA- 

15 enabled user that registers with the ASON controller. 


In one embodiment, an authentication server is used to authenticate 
OSA-enabled users. The authentication server is typically a centralized 
database that uses an authentication protocol for authentication. The 
20 authentication protocol can use any of a variety of authentication techniques, 
such as challenge-based handshake authentication or simple 
username /password based authentication. 

In another embodiment, each ASON controller 340 uses public key 
25 technology (i.e., authentication certificates) to authenticate OSA-enabled users 
that register with it. This requires that the OSA understand and manage 
authentication certificates for the OSA-enabled user. 


Data security is a user-based feature that needs to be implemented at 
30 the edge of the enterprise network. The OSA software need not support data 
integrity. 
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Architecturally, the OSA-N functionality can be implemented in 
different ways. The suitability of a particular OSA-N architecture depends on 
a number of characteristics, such as such as implementation complexity, fault 
tolerance, UNI bandwidth utilization, UNI signaling delay, memory 
5 utilization, and computational complexity. Because OSA-N is layered on top 
of the ASON UNI, an important consideration is the UNI bandwidth 
utilization and signaling delay for OSA signaling. Latency is important 
because it affects the type of applications OSA can support. 

A number of exemplary OSA-N architectures, namely a client-server 
architecture, a distributed flooding architecture, a hybrid /proxy architecture, 
and an ASON-coupled architecture, are discussed herein. It should be noted, 
however, that the present invention is in no way limited to any of the 
described OSA-N implementations or to any particular OSA-N 
implementation. 

In the client-server architecture, most of the OSA-N functionality, 
including authentication, registration, and group membership, is handled by 
an optical service server (OSS), as shown in FIG. 12* The OSS maintains 
authentication, registration, and group membership information for multiple 
OSA-enabled devices. The OSA-enabled user is typically pre-configured with 
a group identifier. When the OSA-enabled user is attached to the ASON 120, 
the OSA-N sends a registration message to the OSS. The OSA-N includes its 
group identifier in the registration message. The OSS stores the group 
identifier in its registration database. The OSA-N queries the OSS to obtain 
group membership information that includes the identity and location of peer 
users. 

FIG. 13 is a message flow diagram depicting various exchanges 
30 between the OSA-N and the OSS in the client-server architecture. The OSA-N 
sends a registration message 1302 to the OSS including the group identifier 
(ID) for the OSA-enabled user. The OSS stores the group identifier in its 


10 



25 
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registration database. The OSA-N then sends a query message 1304 to the 
OSS to obtain group membership information that includes the identity and 
location of peer users. The OSS sends peer information 1306 to the OSA-N in 
response to the query 1304. 

5 

The client-server architecture has a number of characteristics that are 
considered to be advantages. First, the client-server architecture is relatively 
simple to implement. Second, the amount of signaling bandwidth (both UNI 
and NNI) is relatively small, in part because group membership information 
10 is maintained and distributed by the OSS and therefore there is no need to 
advertise group membership information to the network. Signaling 
bandwidth can be further reduced by having the OSA-N cache the group 
membership information it retrieves from the OSS, with a periodic refresh 
technique used to keep the cache current. 

15 

The client-server architecture has a number of characteristics that are 
considered to be disadvantages. First, the OSS represents a single point of 
failure so that, if the OSS fails, the network cannot perform authentication, 
registration, and group membership functions. This problem can be 

20 mitigated by running a "backup" OSS and using a synchronization protocol , 
such as the Server Cache Synchronization Protocol (SCSP) as described in 
RFC 2334, to maintain synchronization between the servers, although this 
adds implementational complexity. Second, because the client-server 
architecture is server-based, the network is heavily dependent upon the 

25 availability, reliability, and performance of the OSS, which could become a 
bottleneck for overall system performance, specifically in terms of delay. 
Third, like other types of centralized solutions, the client-server architecture is 
not scalable. Fourth, in order to register with the OSS, the OSA-enabled user 
must be manually configured with its group identifier. 

30 

In the distributed flooding architecture, authentication is handled by 
the OSS, as shown in FIG. 14. The OSS maintains authentication information 
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for multiple OSA-enabled users, and also maintains a group identifier for 
each OSA-enabled user. After authenticating an OSA-enabled user, the OSS 
informs the OSA-enabled user of its group identifier. The OSA-enabled user 
then informs the other OSA-enabled users in the network of its group 

5 membership, specifically by flooding an advertisement through the network, 
for example, in a manner similar to OSPF-TE and PNNI Augmented Routing. 
This flooding occurs periodically and, since the procedure is similar to that of 
OSPF and PNNI, inherits the advantages of both protocols. The link state 
advertisement (LSA) and neighbor database is maintained in the user domain 

10 rather than in the network domain. 


FIG. 15 is a message flow diagram depicting various exchanges 
between the OSA-N and the OSS in the distributed flooding architecture. The 
OSS authenticates the OSA-N through a number of exchanges 1502. After 
15 authenticating the OSA-N, the OSS determines the group identifier (ID) for 
the OSA-enabled user, and sends a group identifier (ID) 1504 to the OSA-N. 
The OSA-N sends an advertisement message 1506 into the ASON. The 
advertisement message 1506 is flooded throughout the network. 

20 The distributed flooding architecture has a number of characteristics 

that are considered to be advantages of the distributed flooding architecture. 
First, it allows centralized policy as to which OSA-enabled users can join a 
group. Second, it does not require manual configuration of the group 
identifier, and instead uses the OSS to distribute the group identifier after 

25 authentication of the OSA-enabled user. Third, it is well-suited to IP-router 
end systems, since OSPF is an extensible IP protocol by virtue of Opaque Link 
State Advertisements (LSA). 

The distributed flooding architecture has a number of characteristics 
30 that are considered to be disadvantages of the distributed flooding 

architecture. First, if the OSS is out of service, then the OSA-enabled user will 
not be able to authenticate and determine its group identifier, and so the 
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OSA-enabled user will not be able to determine its peers automatically. This 
problem can be mitigated by providing peer information to the OSA-enabled 
user manually, which would allow connections to be made using the ASON. 
In this respect, the distributed flooding architecture advantageously separates 
optical network operation from the availability of the OSS and allows the 
OSA to own most of the intelligence. Second, the flooding mechanism uses 
extra bandwidth in the ASON signaling network (both UNI and NNI), which 
can be particularly problematic if the UNI has limited bandwidth. Third, 
flooding does not occur until authentication is complete. Fourth, an OSPF- 
based flooding mechanism requires IP support, and is therefore not suitable 
for non-IP routers. Fifth, because the LSA and neighbor database is 
maintained in the user domain rather than the network domain, topological 
information must be "leaked" to the OSA-enabled user, which can be done by 
implementing some form of NNI in the UNI and thereby confusing the 
separation between the NNI and the UNI. 

In the hybrid/proxy architecture, authentication and flooding are 
handled by the OSS, as shown in FIG. 16. The OSS maintains authentication 
information for multiple OSA-enabled users, and also maintains a group 
identifier for each OSA-enabled user. After authenticating an OSA-enabled 
user, the OSS floods the advertisement on behalf of the OSA-enabled user, for 
example, using a mechanism similar to Proxy-PAR. 

FIG. 17 is a message flow diagram depicting various exchanges 
between the OSA-N and the OSS in the hybrid/proxy architecture. The OSS 
authenticates the OSA-N through a number of exchanges 1702. After 
authenticating the OSA-N, the OSS determines the group identifier (ID) for 
the OSA-enabled user, and sends an advertisement message 1706 into the 
ASON. The advertisement message 1706 is flooded throughout the network. 

The hybrid/proxy architecture is similar to the distributed flooding 
architecture, and therefore has many of the same advantageous and 
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disadvantageous characteristics as the distributed flooding architecture. 
However, because the OSS rather than the OSA-N floods the advertisement, 
the OSS does not need to "leak" topological information to the OSA-enabled 
user. Therefore, there is no confusion of the separation between the NNI and 
5 the UNI. 

In the ASON-coupled architecture, the various OSS services described 
with reference to the client-server architecture are handled by the ASON 
devices at the periphery of the ASON 120, with each ASON device acting as 

10 the OSS for its directly attached OSA-enabled device. The ASON-coupled 
architecture has many characteristics that are considered to be advantages of 
the ASON-coupled architecture. First, because there is no central server, 
network performance does not depend upon the availability and reliability of 
a single server. Second, because an ASON device services only its directly 

15 attached OSA-enabled user, a failure of the ASON device affects only the 

directly attached OSA-enabled device. Third, the ASON-coupled architecture 
is scalable, particularly because of the one-to-one mapping between clients 
and servers, and also because the ASON device only needs to maintain 
advertisements for the group associated with its directly attached OSA- 

20 enabled user. Fourth, the amount of UNI signaling bandwidth is relatively 
small. Fifth, because link state advertisements are stored by the ASON device 
rather than in the user domain, the ASON device can detect a failure of its 
directly attached OSA-enabled user and invalidate the link state 
advertisement for the OSA-enabled user, thus allowing peer users to more 

25 quickly detect the failure of the OSA-enabled user (otherwise, the peer users 
would need to wait for a link state advertisement timeout to detect the failure, 
which, in OSPF, is typically a MaxAge of 1 hour). Sixth, because the ASON 
device is already running ASON-specific OSPF, adding extra link state 
advertisements into the link state database is relatively easy. Seventh, 

30 because no topological information needs to be "leaked" to the OSA-enabled 
user, the separation of UNI and NNI is clear. Eighth, because the link state 
advertisements are handled by the ASON device, the OSA-enabled user does 
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not necessarily need to implement OSPF, which can be a big advantage in 
certain applications. 

Of the four OSA-N implementation architectures described above, the 
5 ASON-coupled architecture seems most suitable for typical applications, 

particularly because of its clearly defined separation of UNI and NNI, flexible 
implementation platforms, and simplicity for client systems. OS A- A must be 
customized on a case-by-case basis and requires a lot of close work with 
customer. 

10 

As discussed above, both the ASON-enabled user and the OSA- 
enabled user implement at least some of the ASON UNI functionality for 
obtaining communication services from the ASON 120. The OSA-enabled 
user additionally includes the OSA 610 for performing a variety of advanced 
15 communication services using the ASON UNI. 

As shown and discussed with reference to FIG. 5 above, two ASON- 
enabled users can communicate over the ASON 120 using the ASON UNI. 
However, the types of communication services available to the ASON- 
20 enabled users is essentially limited to those that are provided directly by the 
ASON 120. 

On the other hand, an OSA-enabled user can interoperate with ASON- 
enabled users and/or with other OSA-enabled users over the ASON 120. 
25 When interoperating with other OSA-enabled users, a full set of OSA-enabled 
features can be supported end-to-end across the ASON 120. When 
interoperating with an ASON-enabled user that does not support OSA, only a 
limited set of features can be supported end-to-end across the ASON 120 
(such as setting up an optical communication path through the ASON 120). 

30 

FIG. 18 shows an exemplary communication system 1800 in which an 
OSA-enabled user 1810 communicates with an ASON-enabled user 1820 over 
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the ASON 120. The ASON-enabled user 1820 implements some or all of the 
ASON UNI. The OSA-enabled user 1810 implements advanced functions 
using the ASON UNI. Because the ASON-enabled user 1820 does not 
implement OSA functionality, the OSA-enabled user 1810 and the ASON- 
5 enabled user 1820 can support only a limited set of features end-to-end across 
the ASON 120. For example, using the ASON UNI, the OSA-enabled user 
1810 and the ASON-enabled user 1820 can establish an end-to-end optical 
communication path for communicating over the ASON 120. 

10 FIG. 19 shows an exemplary communication system 1900 in which two 

OSA-enabled users 1910, 1920 communicate over the ASON 120. The OSA- 
enabled users 1910, 1920 implement advanced functions using the ASON 
UNL Because both OSA-enabled users 1910, 1920 implement OSA 
functionality, the OSA-enabled users 1910, 1920 can support a full set of 

15 features end-to-end across the ASON 120. 

In order to manage various communication services, the OSA 610 
includes optical service logic that implements application-specific services 
and intelligence. The optical service logic interacts with the ASON 120 via the 

20 ASON UNL The optical service logic also interacts with other OSA-enabled 
users via a peer-to-peer signaling mechanism. The peer-to-peer signaling 
mechanism enables communication between OSA-enabled users within a user 
network and/or across the ASON 120. Thus, using the peer-to-peer signaling 
mechanism, OSA-enabled users within the user network can interoperate 

25 over intra-domain signaling channels, and OSA-enabled users at the edge of 
the ASON 120 can interoperate across the ASON 120 over ASON signaling 
channels. Among other things, the peer-to-peer signaling mechanism 
effectively extends OSA functionality to OSA-enabled users that are not at the 
edge of the ASON 120. 

30 

It should be noted that, while the OSA-enabled users at the edge of the 
ASON 120 implement the ASON UNI and interact with the ASON 120 via the 
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ASON UNI, OSA-enabled users that are not adjacent to the ASON 120 are 
unable to interact directly with the ASON 120 via the ASON UNI. Therefore, 
such OSA-enabled users cannot directly access ASON services. Such OSA- 
enabled users can, however, channel ASON service requests through the 

5 OSA-enabled user at the edge of the ASON 120 using the peer-to-peer 

signaling mechanism. Specifically, an OSA-enabled user forwards an ASON 
service request to an OSA-enabled user at the edge of the ASON 120 using the 
peer-to-peer signaling mechanism. In turn, the OSA-enabled user at the edge 
of the ASON 120 interacts with the ASON 120 via the ASON UNI to execute 

10 the ASON service request, and responds if necessary using the peer-to-peer 
signaling mechanism. 

Certain communication services can be managed by a single OSA- 
enabled user. However, other communication services require that a number 
of OSA-enabled users interoperate to coordinate communication services. 
This is particularly true when communication services are coordinated end- 
to-end between peer OSA-enabled users across the ASON 120. In order for 
OSA-enabled users to interoperate, each OSA-enabled user needs to identify 
its peer OSA-enabled user's and obtain various types of peer information for 
each peer OSA-enabled user, such as an attachment address that is used for 
establishing an optical communication path to the peer OSA-enabled user. 
Therefore, the OSA typically includes mechanisms for identifying peer OSA- 
enabled users and for obtaining the peer information. 

25 In a typical embodiment of the present invention, the OSA includes 

auto-discovery logic by which an OSA-enabled user automatically discovers 
its peer OSA-enabled users and obtains the various types of peer information 
for each of its peer OSA-enabled users. The auto-discovery logic typically 
uses an advertisement mechanism for exchanging peer information between 

30 OSA-enabled users, similar to the exchanging of link state advertisements by 
OSPF, although the auto-discovery logic is not limited to any particular 
advertisement or discovery mechanism. Each OSA-enabled user typically 
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includes a peer database in which the peer information is stored. It should be 
noted that peer information can also be configured manually, for example, by 
a network administrator. 

5 In addition to identifying peer OSA-enabled users, it is typically 

necessary or desirable for each OSA-enabled user to authenticate its peers. 
Peer authentication is important because OSA operations can affect such 
things as the integrity of the ASON 120 and of the network as a whole. 
Therefore, the OSA typically includes peer authentication logic for 

10 authenticating peer OSA-enabled users. The peer authentication logic 

typically uses public or private key technologies for authentication, although 
the peer authentication logic is not limited to any particular peer 
authentication mechanism. 

15 FIG. 20 shows the relevant components of the OSA 610. Among other 

things, the OSA 610 includes network management logic 2010, optical service 
logic 2020, peer database 2030, auto-discovery logic 2040, ASON UNI 2050, 
peer-to-peer signaling logic 2060, and peer authentication logic 2070. 

20 The network management logic 2010 provides for configuration and 

control of the OSA 610. Among other things, the network management logic 
2010 interfaces with the network management/ optimization elements 380 in 
the ASON device via the network management interface 620, and also enables 
remote control of the OSA 610 by a network administrator. For example, the 

25 network administrator can manually configure peer information in the peer 
database 2030 via the network management logic 2010. 

The optical service logic 2020 implements application-specific services 
and intelligence. The optical service logic 202 interacts with the ASON 120 
30 via the ASON UNI 2050. The optical service logic 2020 also interacts with 
other OSA-enabled users via the peer-to-peer signaling logic 2060. The 
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optical service logic 2020 may utilize peer information stored in the peer 
database 2030. 

The peer-to-peer signaling logic 2060 enables the OSA-enabled user to 
communicate with other OSA-enabled users within a user network and/ or 
across the ASON 120. Among other things, the peer-to-peer signaling 
mechanism effectively extends OSA functionality to OSA-enabled users that 
are not at the edge of the ASON 120. The peer-to-peer signaling logic 2060 
may utilize peer information stored in the peer database 2030. 

The auto-discovery logic 2040 enables the OSA-enabled user to 
automatically discover peer OSA-enabled users within a user network and/ or 
across the ASON 120. The auto-discovery logic 2040 typically uses an 
advertisement mechanism for exchanging peer information between OSA- 
enabled users, similar to the exchanging of link state advertisements by OSPF, 
although the auto-discovery logic 2040 is not limited to any particular 
advertisement or discovery mechanism. The auto-discover logic 2040 stores 
peer information in the peer database 2030. 

The peer authentication logic 2070 enables the OSA-enabled user to 
authenticate peer OSA-enabled users. Peer authentication is important 
because OSA operations can affect such things as the integrity of the ASON 
120 and of the network as a whole. The peer authentication logic 2070 
typically uses public or private key technologies for authentication, although 
the peer authentication logic 2070 is not limited to any particular peer 
authentication mechanism. The peer authentication logic 2070 may utilize 
and store peer information in the peer database 2030. 

FIG. 21 shows exemplary OSA logic 2100 for managing communication 
services. Beginning at block 2102, the logic discovers peer OSA-enabled users 
using a predetermined auto-discovery mechanism, in block 2104. The logic 
authenticates the peer OSA-enabled users using a predetermined peer 
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authentication mechanism, in block 2106. The logic then interoperates with 
the peer OSA-enabled users to manage and coordinate communication 
services, in block 2108. The logic 2100 terminates in block 2199. 

5 In an exemplary embodiment of the present invention, an 

authenticated auto-discovery mechanism combining both auto-discovery and 
peer authentication is used to automatically identify and authenticate peer 
OSA-enabled users. The authenticated auto-discovery mechanism requires 
each OSA-enabled user to register with the ASON using an authenticated 

10 registration mechanism. A centralized advertisement scheme managed by the 
OSS is used to collect and distribute peer information to the peer OSA- 
enabled users associated with a particular peer group. Each OSA-enabled 
user maintains the peer information received from the OSS in its peer 
database. 

15 

More specifically, when an OSA-enabled user needs to access the 
ASON, it first establishes and activates the ASON UNI with a corresponding 
ASON device at the edge of the ASON. The OSA-enabled user then registers 
with the ASON by sending a registration message to the ASON edge device. 
20 The registration message includes, among other things, a group identifier 
identifying the peer group for the OSA-enabled user. 

Upon receiving the registration message from the OSA-enabled user, 
the ASON edge device sends a challenge message to the OSA-enabled user. 
25 The challenge message provides an opportunity for the OSA-enabled user to 
positively identify itself to the ASON through a cryptographic authentication 
mechanism, for example, using predetermined public and/ or private key 
technologies. 

30 Upon receiving the challenge message from the ASON edge device, the 

OSA-enabled user formats a challenge response message. The challenge 
response message positively identifies itself to the ASON device using the 
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cryptographic authentication message. The OSA-enabled user sends the 
challenge response message to the ASON edge device. 

Upon receiving the challenge response message from the OSA-enabled 
5 user, the ASON edge device authenticates the information in the challenge 
response message to verify and positively identify the OSA-enabled user. 
This authentication may require interaction with other network elements, 
such as a certifying authority for public key authentication or retrieval of an 
encryption key from a secure server (possibly the OSS) for private key 
10 authentication. If the ASON edge device is able to verify and positively 
identify the OSA-enabled user through the information provided in the 
challenge response message, then the ASON edge device sends a success 
message to the OSA-enabled user indicating that the registration process is 
complete. On the other hand, if the ASON edge device is unable to verify and 
15 positively identify the OSA-enabled user through the information provided in 
the challenge response message, then the ASON edge device rejects the 
registration, for example, by sending a rejection message to the OSA-enabled 
user. 

20 Upon successfully registering the OSA-enabled user, the ASON edge 

device also sends a join message to the OSS in order to add the OSA-enabled 
user to its peer group. The join message includes, among other things, a 
group identifier identifying the peer group, a user identifier identifying the 
OSA-enabled user, and a bearer identifier identifying the bearer channel 

25 associated with the OSA-enabled user. 

The OSS maintains group membership information for the various 
OSA-enabled users that have registered with the ASON. Upon receiving the 
join message from the ASON edge device, the OSS stores the group 
30 membership information for the new OSA-enabled user identified in the join 
message. If the new OSA-enabled user is the first to register for the particular 
peer group, then the OSS sends a database synchronization message to the 
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ASON edge device listing no peer OSA-enabled users (i.e., a NULL list). 
However, if the new OSA-enabled user is not the first to register for the 
particular peer group, then the OSS sends a database synchronization 
message to the ASON edge device listing the other peer OSA-enabled users, 
5 and also sends an advertisement message to the various ASON devices 
supporting registered OSA-enabled users listing at least the new OSA- 
enabled user. 

Upon receiving the database synchronization message from the OSS, 
10 the ASON edge device determines whether any peer OSA-enabled users are 
listed in the database synchronization message. If there is at least one peer 
OSA-enabled user listed in the database synchronization message, then the 
ASON edge device sends a new neighbor message to the OSA-enabled user 
listing the peer OSA-enabled users and their respective bearer identifiers. 
15 However, if there are no peer OSA-enabled users listed in the database 

synchronization message (i.e., the list is NULL), then the ASON edge device 
typically does not send the new neighbor message to the OSA-enabled user, 
since the peer database maintained by the OSA-enabled user is NULL by 
default. 

20 

Each ASON device that receives an advertisement message from the 
OSS sends a new neighbor message to its respective OSA-enabled user 
including the list of peer OSA-enabled users from the advertisement message. 
The new neighbor message identifies the new OSA-enabled user to all 
25 existing OSA-enabled users in the peer group. 

Upon receiving a new neighbor message from its corresponding ASON 
device, an OSA-enabled user stores the peer information from the new 
neighbor message in its peer database. 

30 

Thereafter, whenever a new OSA-enabled user registers with the peer 
group, the OSS sends an advertisement message to those ASON devices that 
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support registered OSA-enabled devices in the peer group. The 
advertisement message identifies at least the new OSA-enabled user and its 
bearer identifier, and may also list some or aU of the other peer OSA-enabled 
users and their respective bearer identifiers. Each ASON device that receives 
an advertisement message from the OSS sends a new neighbor message to its 
respective OSA-enabled user listing the peer OSA-enabled users and their 
respective bearer identifiers. Each OSA-enabled user that receives a new 
neighbor message from its corresponding ASON device stores the peer 
information in its peer database. 

FIG. 22 is a message flow diagram demonstrating the authenticated 
auto-discovery process between an OSA-enabled user A and an OSA-enabled 
user B. The OSA-enabled user A accesses the ASON through ASON device 
Ol. The OSA-enabled user B accesses the ASON through ASON device 02. 
In this example, it is assumed that the OSA-enabled user A is the first to 
register for the peer group G, and the OSA-enabled user B is the second to 
register for the peer group G. 

In order to register with the ASON, the OSA-enabled user A sends 
registration message 2202 to the ASON device Ol indicating peer group G. 
The ASON device Ol sends challenge message 2204 to the OSA-enabled user 
A. The OSA-enabled user A sends challenge response message 2206 to the 
ASON device Ol. The ASON device Ol sends success message 2208 to the 
OSA-enabled user A, and also sends join message 2210 to the OSS including 
group identifier for peer group G, user identifier for OSA-enabled user A, and 
bearer identifier for the bearer channel to OSA-enabled user A. The OSS 
sends database synchronization (DBsync) message 2212 to the ASON device 
Ol with a NULL list of peer OSA-enabled users. The ASON device Ol does 
not send a new neighbor message to the OSA-enabled user A. 

In order to register with the ASON, the OSA-enabled user B sends 
registration message 2214 to the ASON device 02 indicating peer group G. 
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The ASON device 02 sends challenge message 2216 to the OSA-enabled user 
B. The OSA-enabled user B sends challenge response message 2218 to the 
ASON device 02. The ASON device 02 sends success message 2220 to the 
OSA-enabled user B, and also sends join message 2222 to the OSS including 

5 group identifier for peer group G, user identifier for OSA-enabled user B, and 
bearer identifier for the bearer channel to OSA-enabled user B. The OSS 
sends database synchronization (DBsync) message 2228 to the ASON device 
02 with listing OSA-enabled user A as a peer OSA-enabled user, and also 
sends advertisement message 2226 to the ASON device Ol indicating OSA- 

10 enabled user B as a new peer OSA-enabled user. The ASON device Ol sends 
new neighbor message 2224 to the OSA-enabled user A including peer 
information for OSA-enabled user B, and the OSA-enabled user A adds OSA- 
enabled user B to its peer database. The ASON device 02 sends new 
neighbor message 2230 to the OSA-enabled user B including peer information 

15 for OSA-enabled user A, and the OSA-enabled user B adds OSA-enabled user 
A to its peer database. At this point, the OSA-enabled user A has successfully 
identified and authenticated the OSA-enabled user B, and the OSA-enabled 
user B has successfully identified and authenticated the OSA-enabled user A. 

20 Each ASON device monitors the connection to its corresponding OSA- 

enabled user. If the ASON device detects loss or degradation of the 
connection to the OSA-enabled user (e.g., due to a failure of the ASON UNI, 
the bearer channel, or the OSA-enabled device itself), then the ASON device 
sends a leave message to the OSS to remove the OSA-enabled user from the 

25 peer group. The OSS removes the OSA-enabled user from the peer group, 
and sends an advertisement message to the various ASON devices that 
support registered OSA-enabled users indicating the removed OSA-enabled 
users. Each ASON device in turn sends an update message to its 
corresponding OSA-enabled user indicating the removed OSA-enabled user. 

30 Each OSA-enabled user deletes the removed OSA-enabled user from its 
respective peer database. 
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FIG. 23 is a message flow diagram demonstrating the process of 
removing an OSA-enabled user from a peer group. Upon detecting loss or 
degradation of the connection to the OSA-enabled user, as represented by 
2302, the ASON device Ol sends leave message 2304 to the OSS. The OSS 
5 removes the OSA-enabled device A from the peer group, and sends 

advertisement message 2306 to the ASON device 02. The ASON device 02 
sends update message 2308 to the OSA-enabled user B indicating that the 
OSA-enabled user A is no longer a member of the peer group, and the OSA- 
enabled user B removes the OSA-enabled user A from its peer database. 

10 

It should be noted that, when an OSA-enabled user interoperates with 
an ASON-enabled user, as shown and described with reference to FIG. 18 
above, there is essentially no peer-to-peer relationship between the OSA- 
enabled user and the ASON-enabled user. Consequently, many of the OSA's 

15 peer-to-peer mechanisms are not available for interoperation between the 
OSA-enabled user and the ASON-enabled user. Specifically, the ASON- 
enabled user does not support OSA auto-discovery, peer authentication, and 
peer-to-peer signaling mechanisms. Therefore, the OSA-enabled user 
typically cannot auto-discover, authenticate, and perform peer-to-peer 

20 signaling with the ASON-enabled user. This has certain practical 

implications. For example, an ASON-enabled user receiving a request from 
an OSA-enabled user would be unable to authenticate the OSA-enabled user, 
and therefore would generally have to accept the request unconditionally. 
This poses a security/ reliability risk that may be unacceptable in some 

25 situations. 

It should also be noted that optical communication services may be 
provided by multiple service and infrastructure providers. The OSA can 
manage communication services provided by these multiple service and 
30 infrastructure providers. 
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As discussed above, the OSA is an intelligent agent that manages 
various communication services on behalf of the network user. The OSA 
interacts with the ASON to obtain various communication services, and 
manages those services for the network user based upon predetermined 
5 parameters defined by the network user. The OSA can manage practically 
any communication services that have heretofore been managed manually. 

In an embodiment of the present invention, the OSA manages various 
connection establishment services on behalf of the network user. These 
10 connection establishment services can involve such things as negotiating, 
modeling, and scheduling connection and connection-related services, to 
name but a few. 

The OSA may negotiate various connection and connection-related 
15 services on behalf of the OSA-enabled user. Such negotiation may involve 
such things as obtaining quotes for communication services from one or more 
providers, placing a connection out to bid by one or more providers and 
managing the bidding process for the connection, negotiating costs and other 
parameters for a connection with one or more providers, buying connection 
20 and connection-related services from one or more providers, and selling or re- 
selling connection and connection-related services (e.g., arbitrage), to name 
but a few. In essence, then, the OSA may act as a broker for connection and 
connection-related services. 

25 The OSA may also model one or more connections for the OSA- 

enabled user in order to determine such things as the cost, setup time, and 
other parameters of the connection(s). The OSA may model connections 
based upon such parameters as bandwidth, start time, duration, protection 
scheme, and quality of service (QoS), to name but a few. Such modeling is 

30 typically done before establishing a connection in order to evaluate the cost, 
setup time, or other attributes of the connection(s). 
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In order to model a particular connection for the OSA-enabled user, the 
OS A may interact with the ASON and /or peer OSA-enabled users to 
determine the parameters associated with a connection. The ASON provides 
information relating to the portion of the connection traversing the ASON. 
The peer OSA-enabled users provide information relating to the portion of the 
connection beyond the ASON. The OSA may also compile information 
relating to the portion of the connection on the user side of the ASON. The 
OSA uses any information it compiles along with any information it obtains 
from the ASON and /or peer OSA-enabled users to determine the overall cost, 
setup time, and other parameters for the connection. The OSA may model a 
particular connection with respect to multiple providers so that the OSA- 
enabled user can compare the cost, setup time, and other parameters for the 
different providers, and may involve negotiating various connection 
attributes. The OSA typically presents the modeled connection(s) to the OSA- 
enabled user in a form that is convenient for the user to evaluate the 
connection(s). The OSA-enabled user can then use this modeling information 
to make further decisions regarding one or more connections, such as whether 
or not to establish a connection and, if multiple connections were modeled, 
which connection to establish. 

Whether or not the OSA negotiates and/ or models a connection for the 
OSA-enabled user, the OSA can also reserve various connection and 
connection-related services for the OSA-enabled user and/ or establish a 
connection for the OSA-enabled user. 

More specifically, the OSA may reserve communication services from a 
particular provider in advance of when the communication services are 
needed by the OSA-enabled user, for example, based upon time-of-day/day- 
of-week constraints. This typically involves interaction with the ASON to 
reserve ASON-specific communication services, and may also involve 
interacting with peer OSA-enabled users to reserve OSA-specific 
communication services. The OSA may use such advanced reservation to 
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ensure that the communication services will be available for the OSA-enabled 
user when they are needed (e.g., to provide extra bandwidth to handle pre- 
determined traffic surges) and /or to lock in a price for the connection. 

5 Establishing a connection typically involves interaction with the ASON 

to set up a lightpath having specific attributes, and may also involve 
interacting with peer OSA-enabled users to set up the connection end-to-end 
across the ASON. 

10 In order to utilize bandwidth efficiently, the OSA may aggregate 

multiple optical communication paths over a single connection. Specifically, 
upon receiving a request for an optical communication path, the OSA may 
use the ASON UNI to allocate a connection for the optical communication 
path. Upon receiving one or more subsequent requests, the OSA may map 

15 one or more additional optical communication paths over the allocated 

connection, provided the connection has sufficient bandwidth. A mapping 
protocol, such as multilink PPP (Point-to-Point Protocol), is typically used to 
map the multiple optical communication paths over the connection. 

20 For example, the OSA-enabled user may have an OC-192 SONET 

interface that is channelized to OC-48c and is connected to the ASON 120. 
The minimum channel that can be allocated is an OC-48c channel. In the 
traffic engineering (TE) database maintained by the OSA-enabled user, the 
interface is identified as a link that has 10 Gbps bandwidth. Upon receiving a 

25 TE request for an optical communication path having 1 Gbps of bandwidth, 
the OSA intercepts the request and uses the ASON UNI to allocate an OC-48c 
channel (i.e., the minimum channel that can be allocated in this example). 
Thus, the OC-48c channel is underutilized (i.e., there is spare bandwidth). 
Upon receiving subsequent TE requests, the OSA may map the subsequent TE 

30 requests to the allocated OC-48c channel (assuming there is enough 

bandwidth) instead of allocating a separate OC-48c channel for each TE 
request. The OSA uses an IP interface layered on top of the multiple 
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channelized L2 interface, such as multilink PPP, to map the multiple TE 
requests to the OC-48c channel. 

In order to establish connections and aggregate communication paths, 
5 the OSA needs to determine the bandwidth requirements for the connection. 
Thus, the OSA typically includes bandwidth determination logic for 
determining the bandwidth requirements of the connection. 

FIG. 24 is a logic flow diagram showing exemplary OSA logic 2400 for 
10 managing various connection establishment services on behalf of the network 
user. Beginning at block 2402, the OSA may negotiate various connection and 
connection-related services on behalf of the OSA-enabled user, in block 2404. 
The OSA may also model one or more connections for the OSA-enabled user, 
in block 2406. The OSA may reserve connection and connection-related 
15 services for the OSA-enabled user, in block 2408. The OSA may establish a 
connection for the OSA-enabled user, in block 2410. The OSA may aggregate 
multiple optical communication paths over a single connection, in block 2412. 
The logic 2400 terminates in block 2499. 

20 FIG. 25 is a logic flow diagram showing exemplary OSA logic 2500 for 

negotiating various connection and connection-related services on behalf of 
the OSA-enabled user as in block 2404. Beginning at block 2502, the OSA may 
obtain quotes for communication services from one or more providers, in 
block 2504. The OSA may place a connection out to bid by one or more 

25 providers and manage the bidding process for the connection, in block 2506. 
The OSA may negotiate costs and other parameters for a connection with one 
or more providers, in block 2508. The OSA may buy connection and 
connection-related services from one or more providers, in block 2510. The 
OSA may sell or re-sell connection and connection-related services (e.g., 

30 arbitrage), in block 2512. The logic 2500 terminates in block 2599. 
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FIG. 26 is a logic flow diagram showing exemplary OSA logic 2600 for 
modeling one or more connections for the OSA-enabled user as in block 2406. 
Beginning at block 2602, the OSA may interact with the ASON to obtain 
information relating to the portion of the connection traversing the ASON, in 

5 block 2604. This may involve interacting with multiple providers to obtain 
multiple quotes for communication services, in block 2606, and/ or 
negotiating with one or more providers to obtain favorable terms for the 
OSA-enabled user, in block 2608. The OSA may interact with peer OSA- 
enabled users to obtain information relating to the portion of the connection 

10 beyond the ASON, in block 2610. The OSA may compile information relating 
to the portion of the connection on the user side of the ASON, in block 2612. 
The OSA may present the modeled connection(s) to the OSA-enabled user in 
a form that is convenient for the user to evaluate the connection(s), in block 
2614. The logic 2600 terminates in block 2699. 

15 

FIG. 27 is a logic flow diagram showing exemplary OSA logic 2700 for 
establishing a connection for the OSA-enabled user as in block 2410. 
Beginning at block 2702, the OSA may interact with the ASON to set up a 
lightpath having specific attributes, in block 2704. The OSA may interact with 
20 peer OSA-enabled users to set up the connection end-to-end across the 
ASON, in block 2706. The logic 2700 terminates in block 2799. 

FIG. 28 is a logic flow diagram showing exemplary OSA logic 2800 for 
reserving connection and connection-related services for the OSA-enabled 
25 user as in block 2408. Beginning at block 2802, the OSA may interact with the 
ASON to reserve ASON-specific communication services, in block 2804. The 
OSA may interact with peer OSA-enabled users to reserve OSA-specific 
communication services, in block 2806. The logic 2800 terminates in block 
2899. 

30 

FIG. 29 is a logic flow diagram showing exemplary OSA logic 2900 for 
aggregating multiple optical communication paths over a single connection as 


-38- 


2204-A94-141135 (13072BAUS04U) 
08/15/01 

in block 2412. Beginning at block 2902, and upon receiving a TE request for 
an optical communication path, in block 2904, the OSA establishes a 
connection across the ASON, in block 2906, for example, as described with 
reference to FIG. 27 above. Upon receiving a subsequent TE request for an 
5 additional optical communication path, in block 2908, the OSA may map the 
additional optical communication path to the established connection using a 
predetermined mapping protocol, in block 2910. The logic 2900 terminates in 
block 2999. 

10 It should be noted that the term "router" is used herein to describe a 

communication device that may be used in a communication system, and 
should not be construed to limit the present invention to any particular 
communication device type. Thus, a communication device may include, 
without limitation, a bridge, router, bridge-router (brouter), switch, node, or 

15 other communication device- 
It should also be noted that the term "packet" is used herein to describe 
a communication message that may be used by a communication device (e.g., 
created, transmitted, received, stored, or processed by the communication 

20 device) or conveyed by a communication medium, and should not be 

construed to limit the present invention to any particular communication 
message type, communication message format, or communication protocol. 
Thus, a communication message may include, without limitation, a frame, 
packet, datagram, user datagram, cell, or other type of communication 

25 message. 

It should also be noted that the logic flow diagrams are used herein to 
demonstrate various aspects of the invention, and should not be construed to 
limit the present invention to any particular logic flow or logic 
30 implementation. The described logic may be partitioned into different logic 
blocks (e.g., programs, modules, functions, or subroutines) without changing 
the overall results or otherwise departing from the true scope of the 
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invention. Often times, logic elements may be added, modified, omitted, 
performed in a different order, or implemented using different logic 
constructs (e.g., logic gates, looping primitives, conditional logic, and other 
logic constructs) without changing the overall results or otherwise departing 
5 from the true scope of the invention. 

The present invention may be embodied in many different forms, 
including, but in no way limited to, computer program logic for use with a 
processor {e.g., a microprocessor, microcontroller, digital signal processor, or 

10 general purpose computer), programmable logic for use with a 

programmable logic device (e.g., a Field Programmable Gate Array (FPGA) or 
other PLD), discrete components, integrated circuitry (e.g., an Application 
Specific Integrated Circuit (ASIC)), or any other means including any 
combination thereof. In a typical embodiment of the present invention, 

15 predominantly all of the OS A logic is implemented as a set of computer 
program instructions that is converted into a computer executable form, 
stored as such in a computer readable medium, and executed by a 
microprocessor within the OSA-enabled user under the control of an 
operating system. 

20 

Computer program logic implementing all or part of the functionality 
previously described herein may be embodied in various forms, including, 
but in no way limited to, a source code form, a computer executable form, and 
various intermediate forms (e.g., forms generated by an assembler, compiler, 

25 linker, or locator). Source code may include a series of computer program 
instructions implemented in any of various programming languages (e.g., an 
object code, an assembly language, or a high-level language such as Fortran, 
C, C++, JAVA, or HTML) for use with various operating systems or operating 
environments. The source code may define and use various data structures 

30 and communication messages. The source code may be in a computer 

executable form (e.g., via an interpreter), or the source code may be converted 
(e.g., via a translator, assembler, or compiler) into a computer executable form. 
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The computer program may be fixed in any form {e.g., source code 
form, computer executable form, or an intermediate form) either permanently 
or transitorily in a tangible storage medium, such as a semiconductor memory 

5 device (e.g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a 
magnetic memory device (e.g., a diskette or fixed disk), an optical memory 
device (e.g., a CD-ROM), a PC card (e.g., PCMCIA card), or other memory 
device. The computer program may be fixed in any form in a signal that is 
transmittable to a computer using any of various communication 

10 technologies, including, but in no way limited to, analog technologies, digital 
technologies, optical technologies, wireless technologies (e.g., Bluetooth), 
networking technologies, and internetworking technologies. The computer 
program may be distributed in any form as a removable storage medium with 
accompanying printed or electronic documentation (e.g., shrink wrapped 

15 software), preloaded with a computer system (e.g., on system ROM or fixed 
disk), or distributed from a server or electronic bulletin board over the 
communication system (e.g., the Internet or World Wide Web). 

Hardware logic (including programmable logic for use with a 
20 programmable logic device) implementing all or part of the functionality 
previously described herein may be designed using traditional manual 
methods, or may be designed, captured, simulated, or documented 
electronically using various tools, such as Computer Aided Design (CAD), a 
hardware description language (e.g., VHDL or AHDL), or a PLD 
25 programming language (e.g., PAL ASM, ABEL, or CUPL). 

Programmable logic may be fixed either permanently or transitorily in 
a tangible storage medium, such as a semiconductor memory device (e.g., a 
RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic 
30 memory device (e.g., a diskette or fixed disk), an optical memory device (e.g., 
a CD-ROM), or other memory device. The programmable logic may be fixed 
in a signal that is transmittable to a computer using any of various 
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communication technologies, including, but in no way limited to, analog 
technologies, digital technologies, optical technologies, wireless technologies 
{e.g., Bluetooth), networking technologies, and internetworking technologies. 
The programmable logic may be distributed as a removable storage medium 
with accompanying printed or electronic documentation {e.g., shrink wrapped 
software), preloaded with a computer system {e.g., on system ROM or fixed 
disk), or distributed from a server or electronic bulletin board over the 
communication system {e.g., the Internet or World Wide Web). 

The present invention may be embodied in other specific forms 
without departing from the true scope of the invention. The described 
embodiments are to be considered in all respects only as illustrative and not 
restrictive. 
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